r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

does this handle assoc types used only from item signatures and not from within bodies?

Some changes occurred in tests/ui/sanitizer

cc @rcvalle

does this handle assoc types used only from item signatures and not from within bodies?

This also handles assoc types used from within bodies, by checking type of expr,

She meant the exact opposite. Assoc tys only used in non-bodies (aka "item signatures", i.e., places where we don't infer types, i.e., not fn or const bodies, but e.g., inside ADTs, type aliases, impl headers, etc.).

@fmease Hi, I add some tests for such cases but I'm not sure they are right or good enough. Could you have a look or give some examples? Thanks!

Personally speaking, I was thinking of

trait Trait { type Ty; }

impl Trait for () { type Ty = (); }

pub struct Wrap(<() as Trait>::Ty); // <- use of QPath::Resolved `Ty` in a non-body only

impl Wrap {
    pub fn live(self) { _ = self.0; }
}

or

trait Trait { type Ty; }

impl Trait for () { type Ty = (); }

pub struct Wrap(Inner<()>);
struct Inner<T: Trait>(T::Ty); // <- use of QPath::TypeRelative `Ty` in a non-body only

impl Wrap {
    pub fn live(self) { _ = self.0; }
}

I'm sure my examples can be simplified. Also, I haven't really thought much about all of this yet as I'm just drive-by reviewing, so feel free to correct me anywhere :)

@fmease Added and passed.

But current implementation for struct fields is special. Simply speaking, types of fields in used struct will be marked live directly whether the field self is used or not.

The detail is described in https://github.com/rust-lang/rust/pull/148654/files#diff-719b4f36bbbf3b3bf48683429408f5d27e5633f70c1144a93554bd536d5bf655R753-R764

does this handle assoc types used only from item signatures and not from within bodies?

Yes, such assoc types are handled by visiting predicates of the source items.

@fmease I test and find this also fixes #110332

I am not confident enough that this code works well enough, I am worried about the false positives. E.g., what about projected types on impls:

pub struct A;

trait B {
    type Assoc;
}

impl B for A {
    type Assoc = A;
}

trait C {}

impl C for <A as B>::Assoc {}

What about types used in free-consts, e.g. const X: <A as B>::Assoc = A;?

This either needs to have solid coverage or land as an allowed-by-default lint for now.

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@fee1-dead Added test cases for projectd types on impl and free const.

Sorry, don't have enough time right now

@rustbot reroll

@bors try @rust-timer queue

☀️ Try build successful (CI)
Build commit: 016d8ef (016d8ef60defc90251b80016da593e2c44d26cbf, parent: 42f4793e5a514858221b07ac379029d90353913e)

Finished benchmarking commit (016d8ef): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

Max RSS (memory usage)

Cycles

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 473.087s -> 474.173s (0.23%)
Artifact size: 388.70 MiB -> 388.71 MiB (0.00%)